Integrated Vehicle Health Management Systems (IVHMS) are intended to provide near-real-time corrective responses to component and subsystem anomalies in the complex engineering systems for which they are designed. Corrective responses rely upon diagnostics and prognostics, which are preferably performed in real time to support the near-real-time corrective responses. Real-time automated diagnosis of complicated engineering systems, such as spacecraft, aircraft, and ships, has been an elusive goal.
One element of an IVHMS may be a diagnostic logic, also called a diagnostic engine. Diagnostic engines of various types are known in the art. For example, diagnostic engines that use pass/fail criteria, state machine diagnostic engines, neural net diagnostic engines, and data-mining diagnostic engines are available as COTS products. Some of the types are available from multiple vendors, each having a slightly different interface for input data Various COTS diagnostic engines may each have unique input requirements.
Diagnostic engines are typically used in non-real-time, post-processing applications. Diagnostic engines process inputs which are specifically formatted for the particular diagnostic engine. For example, some diagnostic engines accept only pass/fail indicators, others require formal state variables, still others may take a relational database as an input. Producers of COTS diagnostic engines typically designate the format of the inputs for maximum performance of the COTS diagnostic engine itself. The engines are designed for use in a wide variety of applications with which the COTS diagnostic engine producer is unfamiliar, so tailoring the COTS diagnostic engine to a particular set of available data has been left to the end-user of the COTS diagnostic engine. The expense of providing the data in acceptable input form creates a cost barrier to switching between COTS diagnostic engines, resulting in end-users being uncomfortably reliant on a particular vendor.
Real systems, including systems using an IVHMS, may be telemetered to provide data as to the status of various system elements. The telemetry has a telemetry nomenclature which includes data names, often in mnemonic or abbreviated form, associated with respective data formats, data sources, and similar data attributes. The telemetry nomenclature is typically incompatible with the input requirements of COTS diagnostic engines.
Real systems may further provide data at test points and may provide test data generated during built-in tests or other tests. Test point data may be similar to telemetry but not periodically produced. Test data generally have a test data nomenclature which is incompatible with the input data requirements of COTS diagnostic engines.
The telemetry nomenclature, system model nomenclature, test nomenclature, test point data nomenclature, and the input data requirements for COTS diagnostic engines are uncorrelated and so extensive effort is required to obtain input data for COTS diagnostic engines.
Accordingly, it is desirable to correlate the telemetry nomenclature, the systems model nomenclature, the test nomenclature, and the test point nomenclature to provide inputs to COTS diagnostic engines in a way that does not require extensive effort. It is also desirable to provide an interface between the correlated nomenclature data and one or more COTS diagnostic engines.